A computer network generally includes a number of networking devices, such as switches, routers, and others, connected so as to allow communication among the devices and end station devices such as desktop machines, servers, hosts, printers, fax machines, and others. Each network device has a processor and a memory; status variables and other values in the memory are continuously changed and updated as the device operates. To monitor the status of a device in the network, a network management station transmits a message requesting information over the network to a software program or agent running on the target device. In response, the agent sends a message over the network to the network management station. The communications are carried out according to an agreed-upon protocol, such as the Simple Network Management Protocol (SNMP).
These networks usually consist of many different types of data switching and routing devices, such as switches, routers, and hubs. Each device can have different physical characteristics. New devices, with characteristics that are presently unknown, are being developed. In addition, the characteristics of many network devices may change over time. For example, network device characteristics change when subsystems like boards, network interface modules, and other parts are added or removed from a device. However, maintaining a network requires network administrators and managers to have up-to-date network device information constantly at their fingertips.
One approach is to provide the network with a data collection mechanism or system that can gather information about the network devices and report on it to management. It is desirable for such a network data collection system to adapt to changes in device characteristics. It is also desirable for the data collection system to be extensible, so that it can easily accommodate new device types.
Based on the foregoing, there is a clear need for a network data collection mechanism that allows device characteristics to be added, modified and stored without affecting the underlying data collection mechanism. These characteristics must be specific to each device type. However, it is also advantageous to be able to combine characteristics that describe families of similar devices. Further, it is necessary to determine all the device information, including device types, in a real-time fashion, by gathering it from operating devices.
It is also desirable to have a mechanism that can detect changes in the network and preserve a record of such changes for further analysis, without adversely affecting the data collection mechanism. It is also desirable for the change detection mechanism to be able to identify a network device for which a change has occurred, and determine the details of a specific change.
The type of information a device can provide in this manner depends on the Management Information Bases (MIBs) that are supported by the device. A MIB specifies groups of objects, and each object defines a group of data types. An agent or device supports a MIB if the agent is capable of supplying the type of information defined in the objects specified in the MIB. Most agents or devices can provide the type information defined in the objects specified in certain standard MIBs, known as MIB I and MIB II. The format and layout of MIB II is specified in Request For Comments (RFC) 1213. Additional standard MIBs have been defined for information types not covered in MIB I and MIB II, and new MIBs are being developed on an ongoing basis. However, support for these standard MIBs varies from device to device. An agent may only support a subset of a MIB. Further, many device manufacturers have developed their own proprietary MIBs, and many devices or agents operate in more than one mode. An agent or device working in one mode may support different MIBs or different parts of MIBs than the same agent or device executing in another mode.
Past approaches to collecting information from network devices suffer from numerous distinct disadvantages. For example, one approach used by network management mechanisms and software applications that exist today is to provide a table that stores MIB objects for each type of device that is supported by the application. There is a separate table for each device type. The disadvantage of this approach is that a new table has to be created and patched into the application program in order to collect information from a new type of device. The amount of information stored grows proportionally to the number of devices supported. Also, when the format or type of information being collected is changed, the format of the data store associated with one or more device types may also have to be changed. Accordingly, maintenance of the software becomes unwieldy.
It is known that the MIB objects needed for many device types overlap. For example, two different types of devices may have several MIB objects in common, but also store MIB objects that are not supported by the other type of device. However, past approaches do not recognize such overlap. In past approaches, tables are defined for each device type. There is no way to correlate the MIB objects used by one device with those used by another device. As a result, duplicative information is stored.
Based on the foregoing, it is clearly desirable to have a network information collection mechanism that can adapt to new devices when they are added to a network.
It is also desirable to have a network information collection system that can detect changes in the information that is being collected, and therefore detect changes in the network.
It is also desirable to have a network information collection system that can report changes in the network in a manner that is flexible and independent of any application in which the change information may be used.
It is also desirable to have a network information collection system that operates and adapts to upgrades, updates or other changes in the MIB objects collected for a given device type without requiring reconstruction or recompilation of the system.